1. Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for capability based addressing in a communication network.
2. Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled to and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as Internet Protocol packets, Ethernet Frames, data cells, segments, or other logical associations of bits/bytes of data, between the network elements by utilizing one or more communication links between the devices. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
Customers connect to service provider networks to obtain access to the communication resources provided by the service provider. The customer's network element that connects the customer's network to the provider's network will be referred to herein as a Consumer Edge (CE) network device. A CE may be a bridge, router, work station, or any other network element configured to connect the customer's network to the provider's network.
The network element on the service provider's network that enables the customer to connect to the subscriber's network will be referred to herein as a Provider Edge network device (PE). In a bridged Ethernet network scenario, a PE may be an 802.1 ad bridge. In other network topologies, the PE may be another network device capable of providing connectivity to the customer network. PEs are used on the edge of the network to connect to CEs as well as within the network to enable interconnection between interior domain borders and to interconnect the provider's network with other providers' networks. Within the provider's network, Provider (P) network devices are configured to interconnect PEs. In a bridged Ethernet context, the P network devices may be formed, for example, as 802.1d or 802.1ad bridges. The invention is not limited to this embodiment, however, as other network elements may be used as well.
FIG. 1 illustrates one example of a bridged Ethernet network 10. Although the invention will be described as being particularly applicable to bridged Ethernet networks, the invention is not limited in this manner as the invention may more broadly be applied to other network architectures as described in greater detail below.
As shown in FIG. 1, a provider network 10 contains P network devices 14 configured to interconnect PE network devices 16. The PE network devices are connected to CE network devices 18 or to other PE network devices, for example across an administrative boundary within a domain or at an edge of the domain to another domain.
In a bridged network scenario, virtual LAN segments (commonly known as a VLAN) may be defined so that network elements may be interconnected regardless of physical location. Examples of network elements that provide VLAN connectivity are 802.1q and 802.1ad bridges. The invention is not limited to this embodiment, however, as other network elements may be used as well.
In a bridged network, loops are undesirable since loops within the bridged network allow traffic to circulate endlessly, thus causing congestion on the links forming the loop. Within the provider network 10, loops 12 may be prevented by implementation of a spanning tree protocol within the domain. Spanning tree protocols are generally used to prune links between the bridges to avoid loops from forming in the bridged network. There are several different spanning tree protocols, such as the Spanning Tree Protocol (STP) defined in IEEE 802.1D, Rapid Spanning Tree Protocol (RSTP), which builds on STP by significantly decreasing the convergence times of the spanning tree, Multi-Spanning-Tree (MSTP) which extends RSTP by allowing VLAN segments to be mapped to separate spanning-trees thereby improving the load balancing characteristics of the network, and many other spanning tree protocols.
Loops between the provider and customer network may also be prevented if the customer uses a spanning tree protocol on its network. However, occasionally a customer will not use a spanning tree protocol. In this instance, the customer may unintentionally create a loop. The loop may be direct as illustrated or indirect through several customer devices. Thus, where a customer does not use a spanning tree protocol, it is possible for loops to form in the bridged Ethernet network despite efforts by the service providers to prevent them. Loops enable Ethernet traffic to be bridged endlessly thus increasing congestion on the links forming the loop. Since the presence of a loop has the potential to highly degrade network performance, detection and avoidance of loop creation is desirable.
Additionally, even where a loop is not formed by the adoption of a link on the customer network, a customer may cause the potential for a loop to be formed, such as by enabling a back door connection to another provider's network. FIGS. 2A and 2B illustrate two examples of how a back door may be formed on a customer's network and how that may adversely potentially result in the formation of a loop. In these two examples, it is assumed that the two PE/CE connections are to different providers, although the same situation may occur where the PEs are owned by the same provider. As shown in FIG. 2A, a back door may exist where a customer contracts to obtain network connectivity from two different providers and a CE network device is used to connect to both network providers. Connecting to two different providers may be advantageous for redundancy purposes. However, where the providers' networks are connected, the potential for loop formation occurs. Similarly, as shown in FIG. 2B, the potential for loop formation may occur where the customer connects to two different providers using different CE network devices that are otherwise connected by the subscriber network.
Network operators need to be able to verify network performance and to reduce operational costs. To facilitate this, the concept of Operation, Administration, and Maintenance (OAM) functionality has been developed and is documented in International Telecommunication Union (ITU) draft standard Y. 1730: Draft Recommendation Y.17ethreq (Y. 1730) (Requirements for OAM functions in Ethernet based network), the content of which is hereby incorporated herein by reference. As set forth in this draft standard, OAM functionality is generally viewed as important in public networks for ease of network operation, for verifying network performance, and to reduce operational costs.
Since Ethernet provides a unique connection oriented layer network and a connectionless layer network, there will be failure modes that are only relevant to Ethernet. Thus, it is also important that Ethernet have its own OAM functionality. One of the general requirements for Ethernet OAM functionality is that it be configured to automatically detect unintended self-replication, such as may be caused by looping.
Providers may test their networks and their customer's networks by inserting Operation Administration and Maintenance (OAM) frames or flows onto the network and observing their behavior on the network. If the behavior is not as expected, i.e. the flow doesn't pass through the network, there is a problem on the network that will need to be isolated and resolved. Ideally, it would be nice to be able to use OAM flows to detect the presence of backdoors and/or loops created by customer network configurations. Unfortunately, OAM flows are not well suited for testing for the presence of backdoors and/or loops because the loops and backdoors involve unknown, and hence unaddressable, network elements.
One proposal to use OAM flows to detect loops in a bridged Ethernet network has been presented by Muneyoshi Suzuki entitled Loops Detection OAM for Provider Bridged Network, the content of which is hereby incorporated herein by reference. In this proposal, an OAM flow is injected into a customer edge network device with an identification of the provider edge network device that injected the frame. If the frame is later received by the PE device, it can be assumed that it passed through the customer network and that a loop has formed. One disadvantage to this solution is that if a loop actually exists, traffic on the loop is likely to be relatively high thus increasing the chances that the OAM frame will be dropped and, hence, destroying the ability of this method to detect the presence of a loop. Accordingly, it would be advantageous to have a way of performing OAM analysis of a network to detect the presence of loops or backdoors on the bridged network.